1. Field of the Invention
The present invention relates to Internet protocol (IP) telephony servers configured to manage and control telephone communication performed via IP networks, and more particularly, to a Session Initiation Protocol (SIP) server that uses SIP as a protocol for initiating, changing, and terminating multimedia sessions over IP networks.
2. Description of the Related Art
SIP is a protocol proposed by the Internet Engineering Task Force (IETF) SIP Working Group and standardized in the Request for Comments (RFC) 3261. Over a network using SIP, among user agents (referred to as “UAs”), communication is performed between a user agent client (hereafter referred to as a “UAC”) initiating a call and a user agent server (hereinafter referred to as a “UAS”) receiving the call via a plurality of proxy servers.
FIG. 6 is a sequence diagram illustrating an exemplary message sequence for describing information regarding a route set in compliance with RFC 3261. Referring to FIG. 6, it is assumed that communication between a UAC and a UAS is performed via server B, server M, and server Y. SIP header names are abbreviated as “RURI” for Request-URI (Uniform Resource Identifier), “RR” for Record-Route, “C” for Contact, and “R” for Route.
An INVITE request, serving as an initial SIP signal, has Record-Route header fields for recording address information of servers via which the INVITE request traverses and a Contact header field containing address information of the initiating endpoint UA. A route header field is constructed from header values of the Record-Route headers and the Contact header. A rule has been adopted in RFC 3261 in which subsequent requests are transferred in accordance with the header values of the Route header. According to the rule, the route information, established by the INVITE request serving as the initial SIP signal, included in the Record-Route header fields should not be changed in subsequent SIP signals and a route set including the header values of the Record-Route headers and the Contact header should be held in a UA.
In this manner, the UAC initiates a request for session establishment using a SIP message, and the request is then routed by SIP servers acting as proxies to the UAS. A response from the UAS is sent via the SIP servers to the UAC. Accordingly, a call session in IP telephony is established.
According to RFC 3261, a SIP server performing proxy processing is not required to manage route set information. Actually, however, a requirement does exist for the SIP server to terminate a session. In particular, there are two types of SIP server configuration: proxy type and back-to-back user agent (B2BUA) type. A B2BUA SIP server must manage route set information in order to act as a UA. A proxy SIP server, which is not required originally to manage route set information, may sometimes be required to manage route set information as needed in such a case the SIP server is required to terminate a session. Accordingly, a typical SIP server, regardless of whether acting as a proxy or a B2BUA, is required to manage route set information on a session-by-session basis, secures a memory area for storing route set information on a session-by-session basis, and stores route set information within the SIP server.
For example, a typical SIP server receives an INVITE request, determines an address of an endpoint UA serving as a receiving party in accordance with basic routing information included in a header field and additional initiator information included in a body, and routes a session to the address determined (for example, see Japanese Unexamined Patent Publication No. 2002-335267).
A typical SIP server notifies a Voice-over IP (VoIP)-address translation apparatus of address translation information on a call-by-call basis. The address translation apparatus translates address information included in a SIP message from an IP address for a private IP network to an IP address for a global IP network and vice versa. In the case of communication between IP telephone terminals connected to the same private IP network, the set-up is done to enable direct communication between the terminals via a single address translation apparatus. In the case of communication between terminals connected over a plurality of private IP networks, the set-up is done to enable direct communication between the terminals via a single address translation apparatus or communication between the terminals via a global network using a plurality of address translation apparatuses in a cooperative manner (for example, see Japanese Unexamined Patent Application Publication No. 2005-72817).
A UA is only required originally to manage route set information for the number of sessions to join (although only one session in a general telephone communication, there is no problem to join a plurality of sessions). If a SIP server is configured to manage route set information on a session-by-session basis in its internal memory, the SIP server is required to store route set information for the maximum number of connections at one time.
FIG. 7A is a diagram illustrating an example of telephone communications performed via plurality of SIP servers. As shown in FIG. 7A, it is assumed that telephone communications are performed around a SIP server 100 (referred to as an observed server) between two UAs among a first UA 201 (UA #1 with IP address “192.168.1.100”), a second UA 202 (UA #2 with IP address “192.168.1.101”), and a third UA 203 (UA #3 with IP address “192.168.1.102”) via proxy servers including a first proxy server 101 (Proxy #1 with IP address “192.168.10.11”), a second proxy server 102 (Proxy #2 with IP address “192.168.10.12”), a third proxy server 103 (Proxy #3 with IP address “192.168.10.13”), a fourth proxy server 104 (Proxy #4 with IP address “192.168.10.14”), and/or a fifth proxy server 105 (Proxy #5 with IP address “192.168.10.15”). It is also assumed that route information is stored in each SIP server in this example. In FIG. 7A, a solid line represents a route of session #1, a broken line represents a route of session #2, and a dotted-chain line represents a route of session #3.
FIG. 7B is a diagram illustrating exemplary route set information stored in the observed server shown in FIG. 7A. In the case where three sessions are established via the observed server 100, as shown in FIG. 7B, character strings indicating address information included in each of route set information of session #1, session #2, and session #3 are managed in a memory of the SIP server 100. Although IP addresses are shown in FIGS. 7A and 7B, fully qualified domain name (FQDN) addresses which can be resolved in a domain name system (DNS) may similarly be used.
More specifically, it is assumed that a SIP server that can allow simultaneous connections of a hundred thousand sessions uses four Record-Route headers per session, and the size of one address data is 256 bytes, which is the general size of the address data. In this case, the amount of memory necessary for managing entire route set information in the SIP server is (Contact header×2+Record-Route header×4)×the maximum number of simultaneous connections, which is calculated as (265 bytes×2+256 bytes×4)×100,000 sessions 1.54 Mbytes. That is, a total of 154-Mbyte memory is necessary. For each session, a 1.54-kbyte memory is necessary to be secured. Further, as the number of Record-Route headers increases, so does the amount of memory required. Since it is necessary to rescue calls during communication, this memory needs to be secured not in a heap area, but in a common memory area.
In particular, to use an active SIP server (hereinafter referred to as an ACT-SIP server) and a standby SIP server (hereinafter referred to as an SBY-SIP server) in combination as a redundantly configured server (hereinafter referred to as an ACT/SBY server), it is necessary to transfer route set information from the ACT-SIP server to the SBY-SIP server before a failure occurs in the ACT-SIP server in order to rescue sessions during switching from the ACT-SIP server to the SBY-SIP server.
A typical SIP server is required to have a high-capacity internal memory (in the above-described specific example, a memory area for recording only route set information requires 156 Mbytes).
In particular, in the case of implementation of the SIP server in redundant configuration (e.g., an ACT/SBY server) for the purpose of ensuring high reliability of IP telephony servers, a memory area required for rescuing sessions must be taken over from the ACT-SIP server to the SBY-SIP server. This involves the memory transfer processing between the ACT-SIP server and the SBY-SIP server during session control. Therefore, the larger the data area for managing route set information, the larger the amount of data transferred. In a highly loaded status, congestion of the SIP server occurs earlier, resulting in deterioration of the performance of the IP telephony servers.
If the memory area required for rescuing sessions exceeds an amount of one time transfer between the ACT-SIP server and the SBY-SIP server, the memory area must be divided into pieces and transferred piece by piece. This has an adverse effect on the performance of the IP telephony servers.